In client-server systems, client processes are typically separate from the service provider, and require inter-process communication with the service provider. Once initiated, client processes typically occupy other system resources in addition to communication resources. For example, in a client-server system wherein the service provider is a Database Management System (DBMS), each client process occupies resources (eg, processes, threads, memory, locks on database data, etc.) in the DBMS. The cumulative resources occupied by clients can be significant, especially in systems which support hundreds, or even thousands of client application processes. It is therefore important for the service provider to deallocate these resources promptly after a client process terminates. Accordingly, client processes are usually designed to notify the service provider upon termination.
In situations where a client process terminates abnormally (for example, termination of the client process by the operating system due to an addressing violation), the service provider is not normally notified that the client has terminated. The client process can no longer notify the service provider because the client process has been terminated. Furthermore, although the operating system is often aware of the termination, since usually the operating system is responsible for the termination, the operating system does not normally notify the service provider that the client process has terminated. The service provider, therefore, must be able to detect the abnormal termination of a client process in order to deallocate the system resources previously allocated to the terminated client. The mechanism for detecting abnormal client termination depends on the inter-process communication mechanism utilized by the system.
In some systems, this communication is facilitated by means of a communication protocol (eg., TCPIP, SNA, NETBIOS). Typically in systems using one of these communication protocols, a polling mechanism is used by the service provider to verify the continued existence of each client at regular intervals. There are two primary disadvantages associated with such polling mechanisms. First, performance of the system is affected because CPU time is required to conduct the polling. Furthermore, such CPU time is used even if no client process abnormally terminates. Second, resources allocated to a terminated client process are not deallocated promptly after termination, but remain allocated until that client is next polled.
Another mechanism for enabling communication between client and server processes involves the utilization of shared memory. In such a system, the client process and the server process communicate by reading and writing to shared memory segments accessible by both. When shared memory is used, operating system mechanisms called semaphores are typically used for controlling client and server access to the shared memory segments by notifying one process when the other process has written data to a shared memory segment. For example, as a client process writes to shared memory, the client process will post (increment) a semaphore, which will in turn notify a waiting process (in this example, the server process) that data is waiting for it in shared memory. The waiting process will then read the data, completing the data transfer.
Semaphores can be used for a variety of purposes, and are more than just simple boolean flags. In particular, a semaphore has associated with it a non-negative integer value, and several types of operations can be performed on a semaphore. For example, operating systems which are UNIX System V Release 4 compliant have the capability of automatically adjusting the value of the semaphore, by "undoing" an operation which was previously performed on the semaphore by a process using the SEM.sub.-- UNDO flag, when that process terminates. For example, if a semaphore was initialized with the SEM.sub.-- UNDO flag and a decrement operation, the operating system will increment the semaphore (ie, undo the decrement operation), when that process terminates.
These features are often used in situations where a series of processes are competing for a particular resource, and the resource can only support a limited number of processes. In these situations, semaphores can be used for controlling access to the resource, with the initial value of the semaphore set at the maximum number of process which the resource can support. Each process attempting to obtain access to the resource will execute an operation to decrease the value of the semaphore by one. If this operation is possible without reducing the value of the semaphore below zero, the process will gain access to the resource, otherwise the process will wait in a queue. The next process in the queue will obtain access to the resource when the semaphore's value is incremented. When the process currently using a resource terminates, the operating system will automatically increment the semaphore's value, thus allowing the next waiting process to have access to that resource.
In systems using shared memory and semaphores as the inter-process communication mechanism between client and server processes, polling mechanisms are typically used for detecting the abnormal termination of a client process. In such a system, a dedicated service provider process polls all client processes at regular intervals. In this manner, the service provider is able to verify the continued existence of its clients. This mechanism suffers from the same disadvantages as the polling mechanisms for the communication protocols discussed above.
A termination detection system which more promptly frees system resources once a client terminates, while using less system resources itself, would be beneficial.